-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: authz rules grant specific #3
base: vitwit/v0.50.5
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't quite understand where are you storing the allowed rules (app-level).
} | ||
|
||
if rules != "" { | ||
contents, err := os.ReadFile(rules) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should validate against allowed list of inputs.
Suppose if the app developers allow only allowed_recipients
, max_amount
for bankMsg.Send type, it should only accept those inputs. You should check the same in the msg_server implementation too. msg.Validate() may be.
x/authz/keeper/keeper.go
Outdated
return err | ||
} | ||
|
||
authzRuleKeys := authz.AuthzRuleKeys{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should formally construct these rules. Or define a type instead of bytes, so we can marshal, unmarshal easily.
I am storing them within the grants. |
That's the grant settings. We need to store the allowed |
Also, please add the description for the PR. Let's do it as some spec style |
app.AuthzKeeper.SetAuthzRulesKeys(ctx, &authz.AllowedGrantRulesKeys{ | ||
Keys: []*authz.Rule{ | ||
{ | ||
Key: sdk.MsgTypeURL(&banktypes.MsgSend{}), | ||
Values: []string{authz.MaxAmount, authz.AllowedRecipients}, | ||
}, | ||
{ | ||
Key: sdk.MsgTypeURL(&stakingtypes.MsgDelegate{}), | ||
Values: []string{authz.AllowedStakeValidators, authz.AllowedMaxStakeAmount}, | ||
}, | ||
}, | ||
}) |
Check warning
Code scanning / gosec
Errors unhandled. Warning
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
x/auth/ante/authz_rules_spec.md
Outdated
# Description | ||
|
||
Problem: | ||
The existing authorization (authz) module lacks the flexibility to grant permissions (authz grants) for various types of messages along with specific conditions or rules. This limitation constrains users from customizing their transaction behavior based on specific needs or strategies. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The existing authorization (authz) module lacks the flexibility to grant permissions (authz grants) for various types of messages along with specific conditions or rules. This limitation constrains users from customizing their transaction behavior based on specific needs or strategies. | |
The current authorization (authz) module lacks the flexibility needed to grant permissions (authz grants) for various types of messages along with specific conditions or rules. This limitation prevents users from customizing their transaction behavior according to specific needs or strategies. | |
To address this issue, we propose enhancing the authz module to support more granular permissions and conditional rules, allowing for greater customization and control over transaction authorization. |
x/auth/ante/authz_rules_spec.md
Outdated
Swapping Reward Tokens: | ||
- Currently, users cannot set a rule to swap their reward tokens or any other tokens for another token with a specified limit. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Swapping Reward Tokens: | |
- Currently, users cannot set a rule to swap their reward tokens or any other tokens for another token with a specified limit. | |
Managing Reward Tokens: | |
At present, users are able to restake their tokens via authz. But it can do more. Currently users are unable to establish rules for swapping their reward tokens as a strategy as it requires IBCTransfer or PacketForward msgs access. It's not secure to give this grant currently as the recipient address can be anything and grantee can behave maliciously. But if there's a way to restrict recipient address to match with granter's address, this problem is solved. This functionality is necessary to enable users to automate and customize their token management strategies effectively. |
x/auth/ante/authz_rules_spec.md
Outdated
Swapping Reward Tokens: | ||
- Currently, users cannot set a rule to swap their reward tokens or any other tokens for another token with a specified limit. | ||
Sending Tokens to Selected Addresses: | ||
- Users are unable to authorize sending tokens to a pre-defined or selected address, restricting the ability to control where tokens are transferred. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Users are unable to authorize sending tokens to a pre-defined or selected address, restricting the ability to control where tokens are transferred. | |
- Users currently cannot authorize sending tokens to a pre-defined or selected address. This restriction limits their ability to control and automate the transfer of tokens to specific recipients, thereby reducing the efficiency and flexibility of their token management strategies. For example, if an organization wants to authorize an accountant to process salaries every month, the current system's limitations prevent this. Implementing an authz grant to recurrently allow a user to send a specified amount to certain accounts would solve this issue. This feature would automate salary payments, ensuring timely and accurate transactions while reducing administrative overhead. |
x/auth/ante/authz_rules_spec.md
Outdated
- Currently, users cannot set a rule to swap their reward tokens or any other tokens for another token with a specified limit. | ||
Sending Tokens to Selected Addresses: | ||
- Users are unable to authorize sending tokens to a pre-defined or selected address, restricting the ability to control where tokens are transferred. | ||
Staking Tokens with Limitations: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
replace it with gov usecase..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, consider spec format of cosmos-sdk. It describes the problem, but clearly explain about solution, conclusion etc instead of PR diff.
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Description
Problem:
The existing authorization (authz) module lacks the flexibility to grant permissions (authz grants) for various types of messages along with specific conditions or rules. This limitation constrains users from customizing their transaction behavior based on specific needs or strategies.
Specific Examples of Limitations:
Swapping Reward Tokens:
Sending Tokens to Selected Addresses:
Staking Tokens with Limitations:
PR diff:
This PR adds a feature which an authz can be granted with some rules,
for example:
Changes:
updated the ante handlers flow to check in the message is executing the authz message and any rules need to be checked before processing the message. if the message is not reaching the rules then it will eventually fail.
added an extra ante handler:
the above snippet checks the rules for
MsgSend
likewise we can add checks to every messages.Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
in the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...